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1.  INTRODUCTION . 


This  task  deliverable  (TASK  #2)  is  targeted  at  articulating  a 
methodology  and  model  for  Information  Management  of  data 
relating  to  the  configuration  of  the  present,  planned,  and 
target  Information  Systems  Resource  (ISR) . 

The  foundation  of  the  methodologies  suggested  in  this  task 
report  are  founded  on  three  basic  principals. 

o  Coordination  and  cooperation  at  all  levels  of  the 
Information  Systems  Management  process  is  both 
desirable  and  critical  to  the  successful  advancement 
of  quality  and  quantity  improvements  of  the  services 
provided  to  the  end-user  community. 

o  Reporting  systems  developed  for  the  management  and 
audit  of  the  operations,  planning  and  engineering  of 
the  Information  Mission  Area  (IMA)  resources  should 
employ  the  latest  technology  available  to  the 
managers  and  the  automation  process  should  result  in 
more  productivity  at  the  action  officer  levels.  The 
resultant  productivity  should  be  measurable  and 
sustainable.  The  automation  process  should  resolve 
repetitive  reporting  problems  at  the  action  officer 
level  as  opposed  to  creating  new 
reporting  requirements. 

o  The  suggested  methodologies  must  be  implemented  by 
the  matrix  personnel,  and  will  utilize ,  and 
institutionalize  to  the  maximum  extent  possible  and 
practical,  information  available  within  the  public 
domain  and  other  Government  agencies .  Every  attempt 
will  be  made  to  capitalize  on  work  already  done  or  in 
progress , 


2.  OVERVIEW. 


The  model  and  reporting  schemes  suggested  in  this  report  are 
not  intended  to  be  a  detailed  treatise  on  one  particular 
technology,  nor  are  they  intended  to  produce  a  detailed 
implementation  plan.  The  ISEC/AIRMICS  element  of  ISC  earlier 
this  year  produced  a  report  titled  "Guide  for  DSS 
Development".  The  methodologies  in  this  report  are  both 
exhaustive  and  applicable  to  the  task  of  developing  a 
Decision  Support  Environment  tor  a  General  Purpose 
Information  Systems  Management  schema.  The  primary  purpose 
of  this  report  is  to  identify  those  resources  presently 
available  with  which  the  ISC/ISEC  community  could  evolve  a 


1 


modern  Decision  Support  System  within  a  rapid  time  frame  and 
with  a  modest  expenditure  of  resources. 


3.  HIGH  LEVEL  MODEL  FOR  A  DECISION  SUPPORT  UTILITY. 


The  model  which  is  illustrated  here  as  Figure  3.1  has  been 
constructed  to  demonstrate  the  scope  of  the  information  flow 
requirements  within  the  Army  community.  Figures  3.2  through 
3.3  further  illustrate  a  need  for  different  data  to  flow  in 
certain  loops  and  via  interfaces  to  both  coordinating  and 
controlling  functions  within  the  DA  Staff,  to  other 
management  agents  within  the  Strategic  and  Sustaining  Base 
communities  as  well  as  other  DOD  and  non-DOD  Information 
Systems  Management  Agents. 

The  premise  of  this  model  is  that  every  action  begins  with  a 
end-user  driven  requirement  and  ends  with  a  product  or 
service  delivered  to  the  end-user. 

Existing  Army  regulations  provide  for  a  number  of  options  for 
an  end-user  to  satisfy  his  requirements  within  the  resources 
available  to  himself  and  his  MACOM.  The  model  will  not  in  any 
way  attempt  to  detract  from  the  end-users  ability  to  satisfy 
his  bottom-up  driven  requirements,  but  will  capture  the 
resource  usage  and  scheduling  information  for  inclusion  in  a 
Total  Information  Systems  Status  and  Reporting  System,  a 
component  of  the  All-Source  Data  Base. 

There  are  essentially  two  types  of  requirements  which  must  be 
accounted  for  in  the  control  and  resource  allocation 
processes.  The  first  is  a  bottom-up  driven  requirement  which 
originates  with  a  user  and  flows  from  the  user  to  his  DOIM, 
and  proceeds  through  a  loop  consisting  of  the  user,  his  DOIM, 
his  MACOM  and  ISC.  The  second  is  a  top-down  driven 
requirement,  with  the  need  originating  above  the  level  of  the 
MACOM.  The  bottom-up  or  a  series  of  bottom-up  requirements 
which  could  not  be  satisfied  via  MACOM  controlled  assets 
could  result  in  the  formulation  of  a  program  which  might  then 
become  top-down  driven. 

Direction  not  withstanding,  the  users  and  planners  are  vying 
for  some  portion  of  a  fixed  asset  resource  which  is  common  to 
all  Information  Systems  users.  A  system  level  view  of  the 
ISR  clearly  demonstrates  that  the  ISR  is  definable  and 
traceable  back  to  the  ultimate  finite  resource  which  is 
budget  dollars. 

Budget  dollars  and  the  resources  they  provide,  have  always 
been  less  than  the  requirements.  Every  indication  available 
points  to  further  reductions  in  the  budget  allocations 
targeted  to  the  ISR,  and  additional  efforts  must  be  expended 
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to  improve  the  value  received  for  each  dollar  spent. 

ISC/ISEC  are  acutely  aware  of  the  need  to  maximize  values  not 
only  in  the  acquisition  but  in  the  maintenance  and  operation 
of  the  systems.  The  Command  and  Control  (C2)  of  the  ISR  is  a 
data  intensive  operation.  The  value  of  the  judgements  made 
regarding  the  retention  of  a  current  asset,  technology 
insertion  or  a  new  resource  have  an  impact  across  the  entire 
delivery  system. 

Modern  Information  Systems  practices  proffer  a  very  extensive 
set  of  management  aids  to  assist  managers  at  all  levels  in 
identifying  and  prioritizing  actions.  The  range  of  aids 
include  widely  used,  off-the-shelf,  spreadsheet  and  database 
programs  to  custom  programs  which  also  provide  a  range  of 
capabilities.  One  example  is  the  production  of  statistical 
information  concerning  performance  of  switching  nodes,  run 
times  of  applications  in  a  mainframe  queue  and  in  some 
instances,  requests  for  service  statistics  on  multiplex 
facilities.  The  objective  in  using  these  aids  is  to  maximize 
the  value  of  all  expenditures  in  the  Information  Systems 
arena.  The  sooner  the  C2  function  of  the  ISR  is  operational 
the  greater  the  value  to  the  information  systems  community 
will  be. 

) 

With  that  in  mind,  DSI  has  constructed  a  Quick-Fix  method 
based  upon  maximizing  the  use  of  existing  resources  and 
technologies.  The  operative  action  is  to  interface  and 
integrate  existing  data  resources  with  analytical  tools  and 
to  develop  and  disseminate  the  results  and  recommendations  to 
the  broadest  segment  of  the  information  systems  community. 
Properly  implemented,  this  action  will  foster  and 
institutionalize  cooperation  and  communications  at  all 
levels . 

The  method  DSI  is  considering  is  a  bridge  product  between  the 
ARPMIS  database  (or  any  other  data  base)  and  another  database 
containing  the  analytical/modeling/simulation  and  decision 
support  tools.  One  technique  being  considered  to  accomplish 
the  merger  is  via  the  ”C"  Language  "Fork  Command". 

The  attachment  to  this  White  Paper  represents  a  technology 
transfer  request  to  Rome  Air  Development  Center  (RADC)  which 
identifies  multiple  resources.  The  list  of  resources  is 
representative,  not  exhaustive,  at  this  point. 


3.1.  Introduction. 

As  the  IMA  reorganization  proceeds  to  its  full 
implementation,  the  DOIM  and  other  action  officer  level 
personnel  in  the  IMA  arena  are  being  tasked  for  ever  greater 
achievements.  Notwithstanding  the  future  development  of  the 
Army  Information  Architecture  and  its  four  underlying 
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components,  the  information  model,  the  data  architecture,  the 
applications  architecture,  and  the  geographic/technical 
architecture,  the  satisfaction  of  a  user's  needs  and 
requirements  in  a  timely  and  economical  manner  has  not  been 
directly  addressed.  In  fact,  providing  the  solution  to  a 
user’s  need  which  is  identified  today  can  easily  take  in 

excess  of  three  years - if  no  major  problems  are  encountered. 

Hardly  a  rapid  response  from  any  point  of  view. 

When  the  acquisition  process  for  hardware,  software  and 
particularly  communications  is  examined  several  significant 
issues  quickly  come  to  the  forefront.  DSI  experience  has 
shown  that  top-down  driven  efforts  are  generally  fielded 
faster  than  bottom-up  efforts.  This  relatively  rapid 
fielding  can  be  attributed  to  high  system/program  visibility 
(normally  of  a  political  nature) ,  strong  support  from  the 
ARSTAFF,  a  concentration  of  effort,  and  adequate  funds.  The 
caveat  is  that  the  lead  time  on  these  top-down  efforts 
generally  fosters  the  creation  of  a  solution  which  no  longer 
accurately  addresses  the  original  problem.  Witness  the 
inability  of  SAILS  to  handle  all  of  the  facets  of  supply 
requisitioning  at  the  installation  level. 

Bottoms-up  efforts  are  characterized  by  manual  or  stubby 
pencil  operations  supplemented  by  few  automation  tools. 

Those  tools  which  are  in  place  are  either  batch  oriented  with 
very  infrequent  updates,  quarterly  in  some  cases,  or  which 
are  not  being  utilized  to  their  greatest  potential.  There  is 
little  that  a  user  or  even  a  DOIM  can  do  to  determine  the 
status  of  say  a  Request  for  Service  after  it  leaves  the 
DOIM's  office.  For  many  users  the  only  real  status  they  see 
is  when  the  vendor  arrives  on-site  to  install  the  circuit. 

This  WHITE  PAPER  proposes  a  model  which  will  address  an 
action  officer  level  Decision  Support  System.  The  All- 
Source  data  base  with  an  internal  Decision  Support  System 
model  proposed  by  DSI  was  conceived  with  the  goal  of  being 
able  to  rapidly  implement  a  solution  to  significant  problems 
using  reasonably  economic  technology. 


3.2.  Conceptual  Operation  of  the  Model. 

A  bottoms-up  requirement  is  the  most  complicated  and  the  most 
difficult  to  manage  by  ISC  personnel.  On  the  surface  this 
seems  a  contradiction.  The  top-down  driven  systems  are 
indeed  very  large,  complex,  and  demand  intensive  management 
by  large  staffs  in  the  PM  and  PEO  offices.  The  matrix 
support  is  provided  by  ISC  and  it  is  becoming  more  extensive 
and  expensive.  Generally,  adequate  resources  are  available 
for  these  systems  because  of  their  high  visibility.  The 
bottom-up  user  driven  requirement  is  almost  insignificant  in 
comparison.  This  lack  of  "importance"  leads  directly  to  a 
user  requirement's  low  visibility  and  a  low  priority  once  in 


4 


the  system.  However,  the  ratio  of  top-down  to  bottom-up 
driven  requirements  is  staggering. 

The  exact  number  of  top-down  systems/programs  is  difficult  to 
accurately  determine  for  several  reasons.  First,  there  is  no 
single  or  clear  cut  definition  of  "top-down".  Generally,  one 
can  say  top-down  systems  originate  at  the  ARSTAFF  or 
equivalent  level  and  are  pushed  down  to  the  users.  Second, 
there  is  no  separate  validation  or  approval  process  for  top- 
down  systems  per  se,  and  lastly,  the  approved/validated 
requirements  list  (IMP/IMMP  data  base)  is  not  static.  A 
baseline  review  with  periodic  follow  ups  of  the  validated 
requirements  in  the  IMP/IMMP  must  therefore  be  the  basis  for 
determining  the  scope  of  the  problem. 

Bottom-up  requirements  also  lack  a  precise  definition  but  are 
clearly  ones  which  originate  at  the  user  level  down  in  units, 
be  it  MACOM,  battation  or  Reserve  center.  Just  as  there  are 
more  users  than  there  are  ARSTAFFs,  bottom-up  requirements 
are  more  numerous  than  top-down  requirements.  Since  the  U.S. 
Army  decided  to  authorize  the  decentralized  procurement  of 
small  computers  and  their  associated  peripherials  and 
software,  users  have  been  busy  buying  hardware  and  software 
in  an  attempt  to  automate  their  total  work  areas  or  just 
single  job  requirements.  This  approach  is  unorganized  and 
does  little  to  alert  the  ISC/ISEC  community  to  the  impact  on 
support  needed  to  sustain  this  growing  automation  base.  The 
sheer  volume  of  users  requesting  support  makes  this  a  prime 
area  of  management  concern  in  this  model.  Especially,  since 
ISC/ISEC  have  not  been  able  to  keep  the  pace  with  the  level 
and  sophistication  of  automation  required  to  provide 
responsive  support  to  the  users. 

Figure  3.1  demonstrates  the  general  flow  of  information 
within  the  Army  community.  This  flow  includes  both  top-down 
and  bottom-up  requirements.  The  flow  also  includes  hardware, 
software  and  transfer  acquisition,  installation,  operation, 
management  and  upgrade  as  required. 

Satisfaction  of  a  users  needs  and  requirements  is  a  difficult 
and  detailed  process.  The  key  assumptions  at  this  point  are 
that  the  need  or  requirement  has  already  been  properly 
identified  and  approved  within  the  IMP/IMMP  process  and  that 
the  appropriate  types  of  funds  are  available.  If  the 
following  discussion  covered  hardware,  software,  and  transfer 
it  would  be  exceptionally  long  because  of  the  numerous 
combinations  and  variations  possible.  Instead  Figure  3.2 
addresses  more  detailed  information  flow  within  the 
Information  Systems  Agents  only  as  it  relates  to  the 
acquisition  of  transfer  capability/capacity  otherwise  known 
as  communications. 

After  the  user  has  gone  through  the  IMP/IMMP  process  and  has 
the  funds  available  he  can  now  begin  the  process  to  register 


the  proposed  system  in  ARPMIS,  the  automated  replacement  for 
DARTS.  Most  users  will  have  to  go  their  local  or 
installation  DOIM  and  initiate  the  request  to  be  registered 
in  ARPMIS.  After  this  registration  is  completed  the  user 
will  then  submit  a  request  to  the  DOIM  asking  that  the 
appropriate  the  communications  capability  be  provided.  If 
the  DOIM  can  satisfy  that  need  with  a  circuit  that  can  be 
procured  within  his  scope  of  authority  such  as  a  local 
business  line  then  the  DOIM  takes  the  appropriate  steps  to 
complete  the  acquisition  and  satisfy  the  user's  need. 

If  the  required  connectivity  exceeds  the  DIOM's  local 
procurement  authority,  the  DIOM  will  generate  a  Request  for 
Service  (RFS)  and  forward  it  to  the  MACOM.  The  MACOM 
validates  the  RFS  and  sends  it  to  the  Army  Commercial 
Circuits  Office  (ARCCO)  at  Fort  Huachuca,  AZ.  If  ARCCO  can 
satisfy  the  requirement  within  its  resources  by  using 
existing  circuit  capacity,  if  available,  it  will. 

If  the  circuit  requires  the  use  of  the  Defense  Data  Network 
(DDN) ,  ARCCO  will  generate  a  Telecommunications  Service 
Request  (TSR)  and  send  it  to  the  DDN  office  in  Washington 
D.C.  They  approve  or  disapprove  the  request.  If  approved 
(they  generally  are) ,  then  a  TSR  is  sent  to  the  Defense 
Communications  Agency  Operations  Center  (DCAOC)  at  Scott  AFB, 
IL. 


DCAOC  will  attempt  to  satisfy  the  users  requirement  within 
its  existing  communications  resources.  If  this  is  possible 
they  send  an  order  to  the  appropriate  vendor (s)  for  action. 

If  DCAOC  can't  satisfy  the  need  with  existing  connectivity 
they  will  send  a  Telecommunications  Service  Order  (TSO)  to 
the  Defense  Commercial  Circuits  Office  (DECCO) . 

DECCO  utilizes  a  Request  for  Bid  to  get  industry  to  bid  on 
providing  the  necessary  service.  When  a  contract  is  signed 
DECCO  sends  a  Completed  Leasing  Action  Message  (CLAM)  to  all 
previously  involved  parties  notifying  they  of  the  expected 
installation  date. 

Eventually,  one  or  more,  maybe  three  or  four  different 
vendors  will  contact  the  local  DOIM  and  user  to  arrange  the 
details  related  to  the  circuit  installation.  After  the 
circuit  is  "turned  on"  an  In  Effect  Report  is  submitted.  The 
purpose  of  this  report  is  to  notify  all  concerned  parties 
that  the  government  has  assumed  responsibility  for  the 
payment  of  the  service  provided. 

As  Bill-Back  or  Charge-Back  comes  on-line  the  user  will  be 
required  to  pay  for  the  service  he  is  using  Until  that  time, 
either  the  Army,  ARCCO  or  the  MACOM  will  pay  for  the  service. 


Figure  3.3  introduces  the  model  which  DSI  is  proposing  will 


address  the  problems  discussed  above  as  well  as  other 
problems  specifically  related  to  acquisition  of  communication 
connectivity  which  will  be  discussed  in  following  paragraphs. 

The  user's  needs  and  requirements  are  the  sole  reason  for  the 
existence  of  the  ISC  community.  It  is  we  who  must  change  to 
meet  the  users  expectations  and  not  the  users  to  meet  our 
expectations.  Most  of  the  time,  a  users  requirements  enter 
the  system  after  they  are  brought  to  the  DOIM.  If  the  DOIM 
can't  satisfy  the  requirement  he  will  submit  a  RFS  to  the 
MACOM  for  validation.  After  this  message  leaves  the  DOIM's 
office  the  DOIM  has  lost  the  ability  to  quickly  and 
accurately  track  the  status  of  that  RFS.  Additionally,  the 
DOIM  has  lost  the  ability  to  influence  the  decision  to  be 
made  about  the  quality  and  quantity  of  the  service  to  be 
provided  to  the  user.  Further,  if  any  of  the  succeeding 
levels  of  command  forget  to  include  the  originating  DOIM  as 
an  INFO  addressee  on  message  traffic  then  the  DOIM  is  even 
more  in  the  dark  than  before.  All  of  the  above  problems  are 
common  occurrences. 

Two  issues  begin  to  surface  at  this  point.  One  is  the 
extremely  long  lead  time  ISC  and  DCA  mandate  on  circuit 
acquisition.  The  published  lead  times,  as  long  as  they  are, 
are  mostly  optimistic.  The  other  problem  is  that  within  ISC 
the  RFSs  and  TSRs  are  paper  records.  They  begin  as  a  written 
request  from  the  user.  The  DOIM  converts  it  to  written, 
formatted  message  and  put  into  the  AUTODIN  system  to  be 
transmitted  to  the  MACOM.  The  MACOM  receives  the  paper  copy 
of  the  message  from  the  message  center,  validates  it,  re-keys 
it  into  another  written,  formatted  message  and  puts  it  back 
into  the  AUTODIN  system  to  be  sent  to  ARCCO.  ARCCO 
essentially  recreates  this  same  process  for  messages  bound 
for  DCA.  They  follow  a  similar  process  generating  AUTODIN 
messages  which  include  all  parties  as  either  the  ACTION 
addressee  or  and  INFO  addressee.  The  format  and  the 
information  found  in  the  message  traffic  at  all  levels  above 
the  user  is  basically  the  same. 

The  procurement  of  a  normal  DDN  circuit,  with  no  changes, 
delays  or  modifications  will  generate  seven  or  eight  separate 
pieces  of  paper  at  the  user  and  DOIM  levels.  The  total  time 
consumed  in  this  effort  approaches  two  years. 

By  implementation  of  DSS  at  the  action  officer 
level  within  this  circuit  procurement  cycle  dramatic 
improvements  can  be  achieved  at  minimum  cost.  The 
improvements  can  be  achieved  by  eliminating  the  need  to 
repeatedly  hand-generate  standard  formatted  messages  which 
are  then  sent  via  AUTODIN  to  all  addressees  and  then  reduced 
back  to  paper  again.  Administrative  time  is  reduced  and 
circuit  procurement  time  is  shortened.  Additionally, 
suspenses  and  status  can  be  determined  quickly  and 
corrective  action  applied  on  the  spot.  The  time  savings 
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achievable  need  further  research.  Total  resources  saved  or 
costs  avoided  will  be  directly  related  and  impacted  by  how 
thoroughly  this  proposed  change  is  implemented  within  the 
ISC/ISEC  community. 

The  primary  advantage  of  ARPMIS  has  been  to  automate  the  Data 
Requirements  Transfer  System  (DARTS)  process.  The  DARTS 
registration  process  was  a  manual  system  and  it  added  at 
least  six  months  to  the  already  lengthy  circuit  acquisition 
process.  The  use  of  DARTS  before  one  could  request  a  circuit 
was  absolutely  mandatory.  If  your  equipment  was  not 
registered  in  DARTS  you  would  never  be  allowed  to  request  a 
DDN  circuit. 

ARPMIS  is  hosted  on  a  computer  in  the  Pentagon  and  each  DOIM 
has  a  terminal  which  provides  access  to  the  database.  This 
allows  rapid  equipment  registration  but  does  little  to 
accelerate  the  RFS  process. 


3.3.  Responsibilities/Suspenses. 

The  suggested  combination  of  an  All  Source  Configuration  Data 
Base,  Decision  Support  Utilities  and  Program  Management 
Support  Systems  at  all  levels  provides  an  opportunity  to  more 
closely  monitor  responsibility  and  to  reduce  the  suspense 
cycles . 

Program  Management  Support  System  development  is  underway 
with  the  peg's,  PM's  and  ISC/ISEC.  Top  Down  requirements 
will  be  captured  and  documented  in  the  respective  Program 
Management  Systems.  A  similar  type  utility  at  the  DOIM  level 
which  is  compatible  with  the  top-down  driven  programs  would 
complete  the  cycle  for  capture  of  resources,  funding  and 
schedules  pertaining  to  a  specific  program  or  program  action 
in  any  of  the  IMA  areas. 

Once  again  a  Decision  Support  Utility  with  cooperative 
processing  attributes  could  serve  as  the  broadcast  agent  for 
actions,  suspense  and  suspense  closings.  Time  lines  could  be 
assigned  for  completion  of  each  action  and  every  action  or 
supporting  element  would  be  keyed  to  the  same  set  of  actions. 
This  would  also  create  an  action  item  audit  trail  at  each  of 
the  action  levels  as  well  as  in  the  All-Source  Data  Base. 


3.4.  Bill  Back/Charge  Back. 

Users  invest  a  great  deal  of  time  and  effort  in  seeking  the 
solution  for  their  needs  and  requirements.  One  of  the  major 
concerns  of  the  user  and  actually  of  all  members  of  the 
government  is  to  avoid  wasting  tax  dollars.  Any  solution 
which  ignores  this  basic  responsibility  is  not  in  our  best 
interest.  This  doesn't  mean  that  the  cheapest  solution  is 
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always  the  least  expensive  solution.  Our  efforts  must  be 
directed  to  the  most  cost  effective  solutions. 

The  Army  has  developed  various  methods  for  the  procurement  of 
different  parts  of  information  systems.  Information  systems 
include  hardware,  software  and  transfer.  The  acquisition, 
distribution  and  support  of  hardware  is  a  well  developed 
methodology  and  is  relatively  efficient.  Software 
acquisition  or  development,  distribution  and  support 
represents  an  order  of  magnitude  of  more  difficulty.  Costs 
are  high  and  difficult  to  control  compared  to  hardware. 
Development  time  as  opposed  to  simple  acquisition  continues 
to  take  longer  and  longer.  While  costs  are  high  they  are 
easy  to  identify  and  charge  back  as  appropriate.  Some  relief 
is  on  the  way  as  new  tools  become  available.  Transfer 
acquisition  and  support  costs  continue  to  escalate  with  no 
relief  in  sight. 

Without  Bill  Back/Charge  Back,  users  are  not  being  fairly 
treated.  Some  are  bill  payers  for  others  without  even 
knowing  it.  ISC  is  attempting  to  implement  this  type  of 
structure  but  results  won't  be  seen  for  years.  Once 
implemented  it  will  be  part  of  an  integrated  system  that  the 
DOIM  and  other  action  officers  can  effectively  utilize?  Will 
it  be  another  "stove-pipe",  batch  oriented  type  of  operation? 

Bill  Back/Charge  Back  must  be  an  integral  part  of  ARPMIS. 
Through  the  action  officer  DSS  it  could  become  an  integrated 
part  of  a  Total  Information  Systems  Status  and  Reporting 
System.  The  end  result  of  this  effort  is  improved  management 
and  cost  reduction.  The  engineering  agency  should  receive 
some  of  the  benefits  from  these  improved  efficiencies.  DSI 
suggests  a  split  between  the  user  and  the  engineering  agency 
on  all  savings  realized  through  this  program.  The  funds 
returned  to  the  engineering  agency  would  go  into  a 
reinvestment  program  to  achieve  further  savings.  A  benefit 
which  then  would  be  achievable  is  the  establishment  of  a 
better  basis  for  funding.  Both  the  requests  for  future 
funding  and  for  the  utilization  of  existing  funding  would  be 
improved . 


4 .  Decision  Support  Tool  Requirements . 


The  need  for  decision  support  tools  fall  into  three 
categories , 


4.1.  Systems  Configuration  Data. 

The  analysis  of  present  systems  in  order  to  ascertain  their 
current  configuration  data  will  require  examining  at  least 


the  following  items. 


MIS/DP  Systems 
o  Hardware 
o  CPU 

o  Peripheral  Sets 

(Tape/Disk/Printers/Scanners/I/O  Controllers  etc) 
o  Software 

o  Operating  System (s) 
o  Utilities 
o  Applications 
Communications  Systems 

o  Local  (includes  LAN  connections) 
o  Wide  Area 
o  Long  Haul 


4.2.  Modeling  and  Simulation  Aids 

The  components  of  an  information  system  exhibit  varying 
capacities  to  "do-work" .  The  measurement  which  is  meaningful 
is  a  unit's  or  element's  ability  to  do  work  in  the 
configuration  it  is  employed  and  with  its  relationship  to 
other  elements  of  the  system. 

One  facet  of  the  system  design  process  involves  the 
measurement  of  a  system's  ability  to  do-work  under  a 
predetermined  set  of  circumstances.  The  predetermined  set 
of  circumstances  can  be  varied  by  mixing  the  types,  quantity 
and  quality  of  do-work  operations  at  one  or  more  points  in 
the  cooperative,  do-work  environment.  Classically  benchmark 
measurements  are  used  for  this  purpose  and  they  provide  a 
one-for-one  measure  of  a  static  state  and  of  introduced 
variable.  The  variable  could  be  the  comparison  of  two  models 
of  the  same  unit  or  a  measure  of  a  unit  to  perform  work  under 
varying  systems  conditions.  A  conditional  change  might  be  a 
reduction  in  I/O  throughput  arising  from  communication  line 
failure(s),  a  change  in  the  mix  of  applications  in  the 
processor  queue  or  any  other  circumstance  dealing  with 
scheduling  or  the  health  and  welfare  of  the  system. 


4.3.  Capacity  Measurement  and  Capacity  Planning. 

Element  and  system  level  capacity  measures  can  and  should  be 
made.  The  measures  should  be  appended  to  the  Configuration 
Management  Data  Base  and  interfaced  to  an  analytical  tool  set 
which  will  enable  the  Information  Systems  Manager  to 
calculate  performance,  excess  capacity  or  means  to  increase 
capacity  to  meet  emerging  capacity  needs. 


5. 


INFORMATION  SYSTEMS  ENVIRONMENT. 


The  Information  Systems  Environment  is  one  of  great 
complexity.  The  multiplicity  of  ways  to  view  of  the 
environment  does  nothing  to  help  simplify  the  problem.  One 
could  describe  it  by  looking  at  hardware,  or  at  software,  or 
at  communications,  or  by  its  functionality,  or  by  its  users, 
or  by  the  architecture  employed,  and  so  on  ad  infinitum. 

The  information  and  discussions  that  follow  are  general  in 
nature  and  are  limited  to  three  specific  areas:  a  review  of 
present  DSSs  in  ISC/ISEC;  identification  of  Information 
System  Resources  available  within  ISC/ISEC;  and 
identification  of  Information  System  Resources  required 
by  ISC/ISEC.  The  identification  of  these  resources  is 
directly  related  to  technology  transfer  and  the  need  for 
better  ways  of  doing  business. 


5.1.  Present  Decision  Support  Systems  in  ISC/ISEC. 

Decision  Support  Systems  (DSS)  are  emerging  at  the  Mainframe, 
Work  Station,  and  PC  levels. 

The  Decision  Support  System  running  on  the  ISC 
Pentagon  System  serves  the  United  States  Army  Decision 
System  Management  Agency  (USA  DSMA)  which  was  organized  in 
the  late  1970 's  as  The  FORECAST  Project  Management  Office.  A 
series  of  analytical  models  were  developed  for  the  Army 
Personnel  Management  community  to  provide  capability  to 
project  the  strength  of  the  Army  components,  and  to  simulate 
the  interactions  of  gains,  losses,  promotions,  and 
reclassifications  to  determine  the  impact  on  policy  changes 
on  the  desired  objective  force. 

In  October  1986,  The  Vice  Chief  of  Staff,  Army  (VCSA) , 
directed  the  establishment  of  the  USA  DSMA  as  an  outgrowth  of 
the  original  FORECAST  Project  Office.  In  addition,  he 
directed  the  establishment  of  a  Decision  Support  Management 
Office  (DSMO)  in  each  of  the  ARSTAFF  agencies.  The  DSMO’s  are 
the  agency  functional  proponents  for  development  of  Decision 
Support  Systems  (DSS)  to  support  their  agency 
requirements,  while  USA  DSMA  serves  as  the  overall 
coordinator,  facilitator,  and  integrator  of  the  various 
agency  development  efforts. 

USA  DSMA  has  a  DSS  Master  Plan  which  is  considered  to  be  an 
evolving  document. 

The  Master  Plan  includes  listings  of  current  users,  and  plans 
to  add  additional  users. 

DSI  reviewed  USA  DSMA's  current  RFP  for  "Technical  Services 
to  Aciiieve  Total  Systems  Integration  for  the  U.S.  Army 


Decision  System  Management  Agency  (USA  DSMA) " .  The  RFP  was 
issued  as  a  Small  Business  Set  aside.  Solicitation  Number 
MDA9093-88-R-104  was  issued  in  August  of  88  and  had  a  closing 
date  of  6  Sept.  88. 

If  one  were  to  consider  the  work  description  in  the  reference 
RFP  and  it's  interfaces  to  other  systems  the  potential  number 
of  subscribers  is  more  than  3,000.  There  are  currently  3000 
PROFS  users  on  the  Mainframe  System. 

Generally  a  mainframe  should  not  be  considered  as  a  good 
environment  for  a  Decision  Support  Utility.  Questions  will 
and  should  arise  relative  to  the  functionality  and  usability 
of  DSS  operation  in  a  Mainframe  environment.  The  DSMA 
Project  is  currently  running  in  contention  with  other 
processes  on  the  Pentagon  Mainframe.  The  DSS  tasks  and  the 
nature  of  the  processes  associated  with  the  highly  iterative 
AX  based  operations  are  not  ideally  suited  to  a  mixed 
application  environment. 

The  nature  of  resource  management  and  operating  systems  (OS) 
restrictions  place  severe  limitations  on  the  performance  of 
Expert  Systems  Shells  in  the  mainframe  environment. 

The  DSS  development  at  the  DA  STAFF  level  is  not  at  this 
juncture  time-sensitive,  and  it  is  not  probable,  that  the 
time  lines  could  be  much  improved  in  the  near  term. 

DSSs  serving  time  sensitive  operations  such  as  maneuver 
control,  dynamic  circuit  allocation  and  post  attack 
reconstitution  are  not  good  candidates  for  mainframe  level 
support . 

Workstations,  PCs  and  Parallel  Processing  Machines  with 
extended  memory  capabilities,  and  rapid  access  to  DASD 
peripherals  constitute  the  best  development  and 
implementation  environment  at  this  time. 

DSSs  have  been  successfully  developed  as  Medical  Diagnostic 
and  in  the  Air  Force  Tactical  mission  planning  areas.  There 
are  many  candidate  areas  for  DSS  in  the  ISC/ISEC  service 
area.  A  list  of  Potential  Candidate  DSS  within  ISC/ISEC  are: 

o  Productivity  in  the  Software  Development  Area. 

o  Bill  of  Material  Preparation  Keyed  to  Equipment  Lists. 

o  Capacity  Planning  at  Major  Processing  Centers 

o  Technology  Insertion  Planning 

o  Network  Planning 

o  Trade-offs  Cost  vs.  Performance 

o  Routing  Optimization 

o  Queue  Optimization 

o  Disk  Interleaving 

o  Automated  Maintenance  Assistants 

o  Dynamic  Reconfiguration  in  Large  Networks 
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o  Navigational  agents  in  Large  Data  Bases  and 
Communications  Networks, 
o  Pre  RFP  Release  Market  Surveys 

Potential  users  of  DSS  tend  to  mistrust  the  power  of  the 
machine,  and  to  view  the  entire  Artificial  Intelligence, 
Expert  System,  Decision  Support  movement  as  being  anti-human. 

In  time,  DSS  will  become  transparent  to  the  user  and  will  be 
embedded  in  many  of  the  man-machine  interfaces.  Products  of 
this  type  are  what  we  should  deliver  to  the  managers  and 
action  officer  level  of  ISC/ISEC. 


5.2.  Available  Information  System  Resources. 


The  following  is  a  general  overview  of  the  available  DSS 
Mainframe  Hardware  and  Software  Configurations. 

HQDADSS  System  Configuration  Summary  for  Hardware: 


CPU:  IBM  3081  Model  K64 

18.3  MIPS 
64MB  Core  Storage 

Two  Processors,  running  as  one  under  control  of  CP. 
16  Channels  on-line,  another  8  being  produced  to 
allow  for  channel  speed  connect  of  distributed 
processors . 


TAPE: 


DISK: 


Four  3420  tape  drives  on-line,  controlled  by  3203 
control  unit. 

3480  cassette  style  drives  in  architectural  plans. 
Both  must  coexist  in  order  to  have  full  interface 
with  other  systems. 


Three  3880 's  controlling  6  channels  of  DASD. 
Upgrade  to  cache  3990 's  in  configuration  stages. 
24  3880  Dual  Density  DASD,  (Model  E  56B  each) , 
totalling  120GB. 


CHANNELS : 

6  -  DASD 

1  -  TAPE 

2  -  TELECOM  (1  per  FEP) 

7  -  LOCAL  COMM  CONTROLLERS  (5  each  32-port  3274  D41 

per  channel) 


Communications : 

Two  3725  Model  1  Front  End  Processors. 

Each  3725  w/  64  low  speed  ports  (up  to  9.6)  and  8 
high  speed  ports  (up  to  56KB) 

Each  with  2  channel  adaptors. 


85  dedicated  communications  lines  (mostly  9.6) 
serving  3274  model  C61  or  C41  control  units  running 
SDLC 

6  dedicated  communications  lines  (4.8)  serving  host 
attached  6670  laser  printers  running  BSC 
9  dedicated  communications  lines  (9.6  -  56KB) 
connecting  HQDADSS  host  to  5  other  hosts  running 
SDLC 

30  -  3274  cluster  controllers  connected  to  ISC-P 
host  using  SNA  connect  to  gain  access  to  HQDADSS 
24  -  D41  model  3274  controllers  carrying  88  3299 
multiplexers  (8  ports  each)  running  BSC 
1  PARADYNE  networJc  connect  box  carrying  32  ports 
for  USAFAC  users  to  connect  (unidirectional)  into 
HQDADSS. 

1  7171  ASCII  Protocol  Converter  with  64  ports  for 
dialup  and  ASCII/ASYNC  terminal  interface  (HIOS) 


USER  LOAD: 

3500  PROFS  user  IDs 

Avg  550  -  600  simultaneous  logons  during  standard 
wor)?day 

65  disconnected  service  machines  (SQL,  ADA,  PROFS) 
Aggregate  CPU  %  bisu  avg  96/ 

Steal/load  seldom  over  0. 

HQDADSS  System  Configuration  Summary  for  Software: 


PROD  NAME  REL  VENDOR 


VM/SP 
HPO  REL 
ASSEMBLER  H 
CMS 

CMS  SORT 
PASSTHRU 
PVM/3101 

VIRTUAL  SPOOL  RDR 

VMMAP 

SMART 

IPCS 

DSF 

DIRMAINT 

IPF 

HOST  FILE  TRF 

VFORCE 

ESE/VM 

INFORMATION  MGT 
QUERY  MANAGEMENT  FAC 
DXT 

CROSS  SYSTEM  PRODUCT 
INFO/SYS 

VIRTUAL  STORAGE  EXTE 
STRUCTURED  QUERY  LAN 


5 

IBM 

5 

IBM 

1 

IBM 

1 

IBM 

1 

IBM 

3 

IBM 

1 

IBM 

1 

IBM 

1 

IBM 

2 

IBM 

4 

IBM 

8 

IBM 

2 

IBM 

1 

IBM 

1 

IBM 

2 

IBM 

1.0 

IBM 

1.0 

IBM 

2.0 

IBM 

2.0 

IBM 

1.1 

IBM 

1.1 

IBM 

3.0 

IBM 

3.5 

IBM 
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A 

STORAGE  AND  INFORMAT 
SQL/EDIT 

SCREEN  DEF  FAC  II 
SQL/REPORT 
CUSTOM  FORMAT  OPTON 
PGF  GRAPHICS  INTERFA 
INTELLECT  VM-SQL/AS 
INTELLECT/SX 
INTELLECT  DBMS  INTER 
KBMS 

SYSTEMWW 

INQUIRE 

EASYTRIEVE 

EZ/SQL 

EZ/KEY 

EZ/KEY 

VMLIB 

VM  PREDICT 
ADABAS /NATURAL 
ADABAS/VM  OPTION 
ADABAS 

SYNC SORT  CMS 

MPSIII 

SYBACK 

)  VMBACKUP 

VMS POOL 
ACF2 

SAS/BASIC 

SAS/AF 

SAS/GRAPH 

SAS/ETS 

RSCS 

HDDI 

DW370 

GDDM 

ACF/VTAM  FOR  VM 
NCP  VER  3 
EP 

SSP  VER 
NTO  REL 
NETVIEW 
TCPIP 

SERIES/1  EDX  PROG 
SERIES/1  EDX  BASE 
COBOL  COMP  &  LIB 
COBOL  INTER  DEBUG 
FORTRAN  COM/LIB  (VS) 
FORTRAN  "G"  COMP 
FORTRAN  COMP  &  LIB 
PL/1  OPT 
PL/1  TRANS  LIB 
DMS 

ISPF/DM 

ISPF 


1.1 

IBM 

1,1 

IBM 

1.1 

IBM 

1.0 

VM  SOFTWARE 

303D 

hi 

303D 

hi 

303D 

hi 

303D 

hi 

303D 

hi 

8802 

hi 

8 

COMSHARE 

86.1 

INFODATA 

3.0C 

PANSOPHIC 

3.0C 

PANSOPHIC 

3. OF 

PANSOPHIC 

3.1 

PANSOPHIC 

3.1A 

PANSOPHIC 

2.2 

SOFTWARE  AG 

1.2 

SOFTWARE  AG 

0.0 

SOFTWARE  AG 

1.8 

SOFTWARE  AG 

6. 1C 

SYNC SORT 

2.0 

KETRON 

2.  OF 

SYNC SORT 

4.1 

VM  SOFTWARE 

1.0 

VM  SOFTWARE 

3.1 

COMP  ASSOC 

5.16 

SASINST 

5.16 

SASINST 

5.16 

SASINST 

5.16 

SASINST 

2.2 

IBM 

2.0 

IBM 

1.0 

IBM 

2.2 

IBM 

3.1.1 

IBM 

3 

IBM 

3 

IBM 

3 

IBM 

2.1 

IBM 

1/2 

IBM 

1.0 

IBM 

5.2 

IBM 

5.2 

IBM 

3 

IBM 

3 

IBM 

3 

IBM 

3 

IBM 

3 

IBM 

4 

IBM 

4 

IBM 

? 

IBM 

1 

IBM 

2 

IBM 

ISPF/PDF 

ISPF/PDF 

PROFS 

WANG /PROFS  GATEWAY 
DCF 

(6670  PRE/POST) 
BUSINESS  BASIC 
STAT  BASIC 
MATH  BASIC 
MPSX 

OMNI CALC 


1 

IBM 

2 

IBM 

2.2 

IBM 

2.0 

WANG 

3 

IBM 

2 

IBM 

1 

IBM 

1 

IBM 

1 

IBM 

1 

IBM 

5.3 

TOWER 

Work  Station,  LISP  Machines,  and  PC  level  development 
environments . 

LISP  Machines,  AI  Inference  Engines  and  the  class  of  high  end 
AI  dedicated  machines  are  generally  too  expensive.  Lisp  and 
Prolog,  the  dominant  AI/ES  languages  require  specialized 
technical  skills  unique  to  the  Knowledge  Engineering  areas 
and  missing  from  the  standard  MIS  type  programmers 
environment . 

A  representative  list  of  single  user  Pc  Shells  includes: 

1.  NEXPERT/OBJECT  COST  $5,000 

Neuron  Data 
444  High  Street 
Palo  Alto,  CA  94301 
415-321-4488 

*  Runs  under  MS-DOS,  UNIX  and  Macintosh  OS 


2.  M,1  and  Copernicus  Cost  range  from  $5,000  to  $  30,000 

Technology  Inc. 

1850  Embarcadero  Rd. 

Palo  Alto,  CA  94303 
415-424-9955 

*  Runs  under  MS-DOS  and  MVS  plus  runs  under  OS  on  Sun  & 
Apollo  workstations. 


3.  Rule  Master  2  &  Rule  Master  PCX  cost  between  $495  &  $1895 

Radian  Corporation 
8501  Mo-Pac  Blvd. 

Austin,  T.X  75380 


*  Runs  under  MS-DOS,  UNIX,  XENIX  and  MVS 


4.  GURU  cost  $6,500  for  Single  user  $17,000  for  LAN  Version 


Micro  Data  Base  Systems  Inc. 

P.O.  Box  248 
Lafayette,  IN  47902 
317-463-2581 

*  Runs  under  MS-DOS,  OS/2,  UNIX,  and  MVS 


5.  XSYS  costs  $395  and  up  depending  upon  cpu 

EXSYS  Inc. 

P.O.  Box  11247 
Albuquerque,  NM  87192 
505-256-8356 

*  Runs  under  MS-DOS,  UNIX  ,  MVS. 


6.  CxPert  $395  for  Object  code  $2 , 000-$4 , 000  for  Source  code 

Software  Plus 
1652  Albemarle  Dr. 

Crofton,  MD  21114 
301-261-0264 


*  Object  Code  runs  under  MS-DOS 

*  Source  Code  is  written  in  C  and  can  compile  on  any  machine 


7.  COSMIC  CLIPS  costs  $250 

University  of  Georgia 
582  E.  Broad  St. 

Athens,  GA  30602 
404-542-3265 

*  Machine  Independent  runs  Under  C  compiler 
**  Originally  developed  by  NASA.  May  be  a  candidate  for  a 
Technology  Transfer  to  Government  agencies. 

Development  of  these  skills  on  this  class  of  machine  should, 
for  the  present,  remain  in  the  R&D  lab. 

Many  shells  and  off-the-shelf  products  are  available  for  the 
single  user  PCs  running  botn  DOS  and  UNIX.  Multi-user 
\'ersions  are  less  a\'ailable  but  becoming  more  common  each 
month . 

The  types  of  DSS  utilities  with  immediate  to  near  term 
application  can  be  developed  and  fielded  on  standard  Army 


hardware  including: 


Zenith-248 
Sperry  5000 
DEC  VAX  Series 
Sun  Workstations 

IBM  PC  and  PS/2  family  and  compatibles 
Apple  II  Series  and  Macintosh 
AT&T  6300  Series 


5.3.  Required  Information  System  Resources. 

The  proper  employment  of  data  base  software  and  DSS  tools  are 
the  key  requirements  for  the  next  step  in  the  evolutionary 
process  of  technology  insertion  and  transfer.  What  data 
bases  are  the  best  candidates  for  upgrading?  A  configuration 
data  base  like  ARPMIS.  What  should  be  in  this  Configuration 
Management  Data  Base? 

First,  the  data  is  to  reside  in  ARPMIS.  As  greater  amounts 
of  data  are  amassed,  the  resulting  data  base  could  be  known 
as  the  All-Source  Data  Base. 

Then  the  first  candidate  application  should  be  the  transfer 
of  intelligent  information  and  options,  concerning  the 
present  state  of  the  Information  Systems  Resource,  and  an 
overlay  of  in-process,  and  planned  change. 

The  present,  in-process  and  planned  status  of  the  information 
systems  should  be  captured  in  electronic  form  in  a  centrally 
controlled  and  managed  data  base. 

Information  about  Status  and  Status  Reporting. 

o  Planned  Information  Systems 
o  Proponent 

o  Matrix  support  being  provided 

o  Description  of  System 

o  Projected  hardware,  software,  and 

transfer  requirements 
o  Initial  Operating  Date 

o  Full  Operation  Date 

o  Operational  life  time  (life  cycle) 

o  Suspense  system  to  tract  milestone 

actions 

o  In-progress  Information  Systems 

o  E’roponent 

o  Matrix  support  being  provided 

o  Description  of  System 

o  Status  of  acquisition  efforts,  HW  and  SW 

o  Status  of  communications/connectivity 

acquisition . 


o 


Present  Information  Systems 
o  Description  of  System 

o  Hardware,  software  and  transfer 

information  should  be  extracted  from  data 
elements  listed  above  in  HW  and  SW 
o  Current  communications  cost  by  circuit 

o  Funding  levels 

o  Acquisition  of  connectivity  for  bottom-up 
requirements 

o  Notification  from  Contracting  offices  and 

PM  shops  on  the  purchase  of  computers  and 
the  ship  to  addresses  of  users 
o  Complete  listing  of  all  data  elements 

needed  for  use  in  the  prescribed  formats, 
o  Listing  of  action  and  information 

addressees 

o  Suspense  system  to  track  action, 

o  Signatory  checks  to  determine  who  is 

working  or  has  completed  the  action, 
o  Billing  information  after  connectivity 

has  been  installed  and  accepted. 

Information  about  the  hardware  (Communications 
/DP/MIS/ANCILLARY) . 

o  Hardware  item  identification  (nomenclature) 

o  Top  level  serial  numbers 

o  Subassembly  serial  numbers 

o  EC  levels  of  top  unit  and  subassemblies 
o  Stock  number  identification  of  all  documentation 
relating  to  the  unit  of  equipment 
o  Stock  number  identification  of  installation  drawing 
package (s ) 

o  Identification  of  Organization  responsible  for 

equipment  support 

o  List  of  all  Engineering  Change  Orders  applicable  to 
this  unit  type 

o  EC  status  of  each  item  of  equipment  within  the 
ISC/ISEC  inventory. 

o  Description  of  how  the  unit  is  used  as  it  is 
configured  in  the  ISC/ISEC  application 
o  Expansion  capacity  of  unit  beyond  its  configured 
state 

o  Description  of  O&M  personnel  skills 

o  MTBF/MTTR  performance  history-performance  history 

should  be  measured  against  manufacturer's  specified 

MTBF/MTTR ' s 

o  Identify  any  special  tools  &  test  equipment 
requirements 

o  Identify  common  tools  and  test  equipment 
requirements 

o  Identify  spare  parts  lists  and  source  information 


o  Identify  units  environmental  requirements  and 

limitations  (TM/REFERENCE  is  adequate)  TM# ,  PAGE, 
PARAGRAPH 

o  Identify  all  software  required  to  function  as 
configured 

o  Identify  additional  software  which  will  run  on  this 
unit 

o  Identify  all  ancillary  and  interface  units 
o  List  Preventative  or  Margin  Checking  Maintenance 
routines  and  the  performance  frequency  of  each 
o  Budgetary  unit  cost  &  support  figures 

Information  about  the  Software. 

o  Functional  description  of  each  unit  of  each  package 

o  Functional  description  of  each  unit  of  code  in  the 

package 

o  Stock  #  identifier  for  each  package 

o  Stock  #  identifier  for  each  unit  of  code 

o  Source  origin  ID  number 

o  COMMERCIAL  ID# 

o  SDCX"  ID# 

o  Other  ID#  (AF,  NAVY,  DC A,  DARPA,  ETC. 

o  Source  ID#  for  product  maintenance  and  development 

o  Source  IDs  for  coding  team  if  government  developed 

package  (audit  back  to  SDC  development  team) 
o  Each  development  center  should  maintain  a  product 

development  history  for  each  software  product.  The 
history  should  include  a  productivity  audit  for 
each  contributor.  The  measure  being  "good  lines" 
of  code  per  day." 
o  Product  development  language 

o  Lines  of  code  per  product 

o  Memory  requirement  for  each  target  environment 

for  this  product 

o  Product  reusability  measurement 

o  Development  history  of  each  product 

o  Cost/schedule  estimate 

o  Cost/schedule  performance 

o  Change  and  updates 

o  Reason  for  change  or  update 
o  Cost/schedule  of  each  change  or  rerelease 
o  System  performance  goals 

o  Actual  system  performance  measurements 
o  Product  Quality  measurement 

o  IV&V  records 

o  Fielding  schedules 

o  Beta  test  verification 

o  Product  portability 

o  Product  interface  requirements 

Information  about  the  Transfer  Utility{s). 

o  DDN 
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o  DSN 

o  PROFS 

o  Common  Data  Carriers 

o  Connectivity 

o  Dedicated 
o  Dial  up 
o  Remote 
o  Speed 


Quite  a  number  of  the  attributes  shown  for  the  ARPMIS/All- 
Source  Data  Base  deal  with  performance  and  post  installation 
performance.  Measurements  such  as  MTBF/MTTR  are  included  to 
demonstrate  the  potential  utility  of  the  All-Source  Data 
Base.  This  data  can  and  should  be  used  by  the  Plans  and 
Program  elements  to  verify  vendor  performance,  by  the  O&M 
functions  to  track  performance  trends  and  by  the  DOIM  to 
schedule  inspections  and  to  identify  training  needs  and 
deficiencies.  Data  dealing  with  personnel  performance  i.e., 
lines  of  good  code  per  day  is  the  type  of  measurement. 
Extending  the  data  beyond  the  source  of  origin  is  not  micro 
management,  but  rather  a  quality  check  on  system  performance. 

The  combined  All-Source  Data  Base  and  Decision  Support  tools 
could  and  should  be  extended  to  include  the  interface  at  EAC 
to  the  tactical  world.  A  complete  merger  of 
Strategic/Sustaining  Base  and  Tactical  is  possible  and 
desirable.  This  merger  could  occur  in  a  evolutionary  fashion 
provided  both  sides  of  the  EAC  interface  follow  the  same 
rules,  data  structure,  etc. 

Information  about  scheduling,  resources  management,  and 
reporting  should  originate  in  an  off-the-shelf  Program 
Management  System  which  is  common  to  ISC/ISEC/PEO/PM  and 
DOIM.  The  level  of  effort  on  this  task  does  not  permit  a 
detailed  review  of  each  of  the  program  management  packages  in 
use  in  the  Army.  Personal  experience  of  the  authors  over  the 
past  several  years  shows  that  there  is  no  single  Program 
Management  Support  System  (PMSS)  in  use,  nor  is  there  a 
consensus  among  those  planning  on  deploying  PMSS  in  the  near 
term . 

There  is  a  general  consensus  that  the  data  base  products  in 
the  PMSS  as  well  as  other  data  bases  should  have  an  SQL 
feature.  A  persistent  problem  is  the  many  different 
implementations  of  SQL.  Far  too  often  the  burden  of  learning 
a  new  set  of  query  commands  is  overlooked  by  the  designers. 
This  is  an  undue  burden  on  the  working  level  and  should  be 
eliminated.  ISC/ISEC  has  made  some  strides  in  this  direction 
with  the  selection  of  XDE  as  the  standard  for  Data  Base  on 
development  products. 

Government  can  not  influence  the  form  and  function  of 
off-the-shelf  products  such  as  PMSS  with  broad  commercial 
application.  A  standard  product  should  be  selected,  if  for  no 
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other  reason  than  to  obviate  the  need  for  operational 
personnel  to  learn  multiple  implementations  of  Query 
Languages . 

The  Decision  Support  Utility  can  access  the  PMSS  elements  and 
extract  resource  data  for  inclusion  in  analysis  and  what-if 
decision  cycles.  The  data  merge  for  information  residing  in 
the  All-Source  Data  Base,  Program  Management  Support  Systems, 
STAMIS  (i.e.,  SIDPERS,  ACPERS,  STANFINS)  and  the  Decision 
Support  System  can  be  managed  by  the  DSS. 


How  should  and  could  the  information  in  the  Configuration 
Management  Data  Base  be  used  to  assist  the  Managers  and 
Action  Officers  in  performing  their  respective  duties? 

Clearly  the  action-officers,  and  more  specifically  the  DOIM's 
should  expect  the  DSS  utilities  to  assist  him/her  in  the 
automation  of  the  routine  and  non-routine  reports  and 
updates . 

The  terminal  devices  used  by  the  DOIM’s,  engineers,  analysts, 
programmers,  et  al,  should  support  linkage  of  their  work 
performance  with  the  All-Source  Data  Base,  STAMIS  and  ISMs 
and  provide  the  same  level  of  service  as  described  in  the 
paragraph  above. 

To  the  maximum  extent  possible  and  practical  those  portions 
of  the  All  Source  Data  Base  which  are  unique  to  a  specific 
installation  or  location  should  be  resident  at  the  user 
terminal  as  should  the  processes  and  aids  needed  to  evaluate, 
proposed  changes.  Changes  which  are  implemented  at  the  DOIM 
or  MACOM  levels  could  then  be  uploaded  to  the  All-Source  data 
base . 

Distribution  of  changes  and  updates  to  other  data  bases 
should  be  done  via  a  cooperative  processing  aid  embedded  in 
the  source  data  base  update  module.  This  action  should  be 
transparent  to  the  end-user.  The  same  DSS  utility  should  be 
used  to  update  PMSS  data  base  as  the  result  of  actions 
requested  by  DOIM  i.e.,  addition  of  DASD  capacity,  new 
circuit  assignment,  etc. 


6.  CONCLUSIONS. 


ISC/ISEC  has  a  long  way  to  go  to  achieve  the  level  of 
efficiency  and  effectiveness  that  is  needed  in  all  le\'els  of 
the  Information  System  Resource  being  used  by  the  Army. 

DSSs  are  the  tools  which  offer  improvement  and  rapid 
evolution  through  modernization.  There  are  no  Decision 
Support  tools  in  the  ISC/ISEC  inventory  which  can  be  readily 


applied  to  the  problems  surfaced  in  this  paper. 

DSIs  interest  has  therefore  been  restricted  to  only  select 
areas  where  significant  problems  exist  and  a  corresponding 
potential  for  improvement  is  apparent.  Those  areas  where  the 
application  of  the  right  technology  at  the  right  place  and  at 
the  right  time  will  yield  the  highest  payoff  for  the  smallest 
expenditure . 

ARPMIS  is  the  key  with  which  ISC/ISEC  can  reach  higher  levels 
of  performance  while  expending  fewer  resources.  ARPMIS  and 
the  data  in  it  are  inadequate  to  meet  the  current  needs.  To 
move  toward  a  more  responsive  and  useful  system  ARPMIS  must 
be  built  up  and  interfaced  with  DSSs,  including  PMSSs.  The 
purpose  being  to  create  and  support  the  All-Source  Data  Base. 
The  All-Source  Data  Base  will  provide  the  DOIM  and  those  at 
the  action  officer  level  with  a  tool  which  will  allow  they  to 
become  more  effective  and  efficient  while  providing  the  user 
with  better  service  which  is  the  ultimate  mission  of  ISC.. 

A  technique  which  can  be  used  to  help  solve  these  problems  is 
to  establish  a  formal  technology  transfer  system,  both 
internally  within  ISC  and  externally  with  other  government 
agencies  and  public  sector  sources.  Technology  extracted 
from  this  system  can  be  applied  against  the  ARPMIS  problem  as 
the  first  priority  and  to  other  areas  as  resources  are  made 
available . 


7.  RECOMMENDATIONS . 


FIRST: 

Establish  AIRMICS  as  the  formal  "Technology  Review  and 
Transfer  Agent"  for  ISC/ISEC. 

An  "All-Source"  Technology  Data  Base  should  be  developed  and 
maintained  by  AIRMICS.  The  source  data  from  the  various 
inputs  should  be  merged  under  major  topic  areas.  Each  entry 
should  include  capsule  information  on  the  program  objective, 
sponsoring  organization  and  points  of  contact. 

The  "All-Source"  Technology  Data  Base  will  provide  the 
ISC/ISEC  planning,  engineering  and  software  developers  with  a 
total  view  of  technical  developments  and  assist  them  in 
extracting  candidate  technologies  in  a  technology  insertion 
program  as  well  as  assisting  the  engineers  and  developers  in 
specification  preparation,  building  candidate  bidders  lists, 
etc . 

The  AIRMICS  connection  to  the  NTIS/DTIS  data  base 
should  be  utilized  by  the  elements  of  ISC/ISEC  and  the 


subcommands.  DSI  has  not  been  able  to  ascertain  that  other 
elements  have  current  access  to  the  DTIS  data  base.  A 
statutory  requirement  exist  for  Market  Surveys  prior  to 
initiating  any  new  project.  A  survey  of  the  DTIC  Data  Base 
should  be  a  given  so  as  to  avoid  duplication  of  effort  or 
paying  for  the  same  efforts  more  than  once.  Assigning  this 
portion  of  the  Market  Survey  requirement  to  AIRMICS  will 
insure  (a)  AIRMICS  involvement  in  the  projects  at  an  early 
stage  (b)  a  high  degree  of  probability  that  the  search  and 
market  survey  was  performed  and  included  the  vast  technical 
data  base  at  DTIC. 


SECOND: 

AIRMICS  should  establish  a  formal  technology  transfer  program 
with  all  DOD  R&D  facilities  who  are  engaged  in  R&D  in  any  of 
the  Information  Systems  areas. 

DSI  suggests  that  the  technology  transfer  program  between 
AIRMICS  and  the  Air  Force  Rome  Air  Development  Center  (RADC) 
could  be  used  as  a  model  to  formalize  the  exchange  of 
technical  data  with  the  other  DOD  components. 


THIRD: 

Data  obtained  via  the  technology  transfer  program  should  be 
captured  in  electronic  form  and  made  available  to  all 
elements  of  the  Army  as  a  service  of  the  AIRMICS  activity. 

A  very  preliminary  estimate  of  the  resources  required  to 
develop,  install  and  activate  the  suggested  data  base  system 
follows : 


o  Hardware 

o  Off-The-Shelf  Software 
o  Labor  to  build  data  base, 
custom  drivers  and  interfaces 
o  O&M  Cost  per  year 


$100,000.00 
$  50,000.00 

$250,000.00 

$100,000.00 


The  cost  of  the  system  would  be  offset  by  saving  in  cost 
avoidance  alone  within  the  first  year.  DSI  tracks  activity 
in  the  Commerce  Business  Daily.  We  have  identified  requests 
for  RFP’s  from  Army  Elements  which  clearly  are  duplications 
of  efforts  underway  within  ISC/ISEC.  One  such  duplication 
originated  in  4th  Army.  The  RFP  was  asking  for  bids  on  a 
major  modification  to  an  existing  program  called  Computerized 
Area  Maintenance  Program  (CAMSAMP) .  The  program  has  identical 
functions  of  one  of  the  Ft.  Sill  ISMs.  This  program  or  one  of 
the  Sill  ISMs  is  a  replication  of  effort.  Avoiding  one  or  the 
other  will  save  the  Army  hundreds  of  thousands  of  dollars  in 
development,  fielding  and  maintenance  costs.  A  judicious 
market  survey  could  have  identified  the  relationship  between 


CAMSAMP  and  the  ISMs. 

The  system  as  conceived  by  DSI  would  be  PC  based.  The 
peripheral  set  would  include  a  suite  of  storage  devices  which 
would  include  fixed  and  removable  hard  disk,  3.5  &  51/4  inch 
FDDs  with  all  density  recording  available,  9  track  and  1/4 
inch  tape.  The  information  in  the  various  databases  from 
which  we  would  propose  to  extract  and  merge  is  in  every  form 
from  paper  reports  to  9  track  tape.  The  system  would  include 
provisions  for  page  and  hand  scanning  and  the  scanners 
selected  would  accommodate  edit  of  the  scanned  images.  The 
delivery  system  would  be  designed  as  a  BBS  with  a  SYSOP 
assigned  to  assist  and  provide  data  in  the  appropriate  forms. 
The  system  would  have  download  and  upload  capability. 

Flexibility  and  expansion  are  the  driving  considerations  at 
this  point.  DSI  is  confident  that  a  baseline  system  can  be 
designed  and  fielded  in  less  than  a  year.  The  system  would 
provide  the  information  System  community  with  not  only 
technology  based  information  but  information  about  the 
activity  in  the  information  systems  procurement  area  (Key  CBD 
announcements  to  Key  Words  in  the  Information  Systems 
Development  Process) . 

Other  sources  of  emerging  and  on-going  R&D  within  the 
government  (DOD  and  Non-DOD  agencies)  should  be  collected  and 
merged  with  like  data  from  the  Small  Business  Innovative 
Research  Program  (SBIR)  and  the  IR&D  programs  of  the 
Information  Systems  Industry.  Access  to  the  IR&D  programs 
should  be  a  part  of  the  technology  transfer  process  between 
AIRMICS  and  the  other  government  agencies 

Use  of  Commercial  Service  On-Line  forums  to  support  technical 
personnel  currency  and  a  hands-on  training  tool.  Several 
User  Bulletin  Boards  offer  special  forums  for  engineers  and 
software  professionals. 

o  NSA  has  a  bulletin  board  with  FORUMS  for  USER 
GROUPS  and  developers. 

o  COMPUSERVE  has  a  number  of  specialized  FORUMS 

dealing  with  AI  and  Expert  Systems.  The  ISC/ISEC 
engineers  and  software  developers  could  benefit 
from  participation  in  this  type  of  FORUM. 


FOURTH : 

Implement  action  to  upgrade  ARPMIS. 

By  the  judicious  use  of  information  being  developed  under 
this  contract  with  DSI  and  additional  information  to  be 
extracted  later  from  the  All-Source  Technology  Data  Base 
recommmended  above,  ARPMIS  should  be  upgraded  to  provide  the 
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services  described  earlier. 


INFORMATION  FI^W  OF  REQUIREMENTS 


community 


